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In an advisory action dated March 14, 2007, the examiner maintains the rejection based 
on the Chirashnya reference, this time using a new explanation. 

Yet, the new explanation, like the old one, fails to show where each element of the claims 
is found or inherent in the reference and, therefore — like the old explanation previously 
contested by the applicant — fails to state a prima facie case of anticipation. 

In the applicant's claim 1, it is after certain network faults are identified that traps are 

generated and sent. The examiner's new explanation appears to address how the faults are 

analyzed but does not address the order of events. As the examiner states: 

Applicant argues that there is no disclosure of generating a batch alarm based 
on the results of "processing information to identify network faults that cause or 
are caused by other network faults," The reference Chirashnya teaches a fault 
notification system by ["] A recommendation and explanation generator 52 
receives the malfunction assessments computed by diagnostic engine 48, and 
compares the assessments for the different modules in network 22 to expected, 
baseline values held in fault model 50. When the failure rate assessment for a 
given module is significantly higher than its baseline value, generator 52 typically 
recommends to the user to take further diagnostic action or to replace the FRU 
containing the module. Criteria for making such recommendations are described 
further hereinbelow. The recommendations are presented via a user interface 54, 
Preferably the user interface also allows the user to input queries to the 
recommendation and explanation generator, and in response to receive a 
comprehensive explanation of the rationale for the recommendation. ["] 

[apparently citing Chirashnya, col. 9, lines 49-63] 

This quoted paragraph from Chirashnya describes what happens after (not before) an 

alarm is generated, as is clear from the preceding column in Chirashnya: 
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A diagnostic engine 48 receives the alarm stream from event formatter and 
merger 40 and uses this information to determine and update reliability 
assessments for the modules . . . The methods used by the diagnostic engine are 
described in detail hereinbelow (col. 8, lines 50-58). 

Figure 3 of Chirashnya also demonstrates that the steps that the examiner apparently 
equates to "identifying network faults that cause or are caused by other network faults and that 
contribute to a failure of a network element" all occur after (not before) step 60 "Receive 
Alarm." The fact that Chirashnya may accumulate faults to generate a batch alarm does not 
change the fact that the analysis of the faults occurs after the alarm. Merely accumulating faults 
until they exceed a certain number is not "processing information to identify network faults that 
cause or are caused by other network faults and that contribute to a failure of a network 
element." Analyzing fault information after an alarm has been generated does not describe and 
would not have made obvious generating traps "based on the results of the information 
processing." 

Moreover, the network faults for which traps are generated in the Chirashnya system are 
not "fewer than air of the network faults that are occurring, as in the applicant's claim 1. To the 
contrary, Chirashnya reports alarms "for each detected fault condition" (see col. 9, lines 47-48) 
or issues a batch alarm when a certain number of faults have accumulated (see col. 13, lines 1-3). 
Reporting an alarm for each fault, whether immediate or cumulative, does not describe and 
would not have made obvious reporting an alarm for "fewer than air of the faults. 

Chirashnya describes neither generating traps "based on the results of the information 
processing" (as in lines 2-4 of claim 1) nor generating traps "with respect to fewer than all of the 
network faults." Either of these reasons is sufficient, even without the other, to show that 
Chirashnya does not anticipate and would not have made obvious claim 1 . With one element 
directly contradicted and another absent, it is factual error to reject claim 1 over Chirashnya. 

Independent claims 10, 1 1, and 13 recite similar features and are patentable for at least 
the same reasons as claim 1. All of the dependent claims are patentable for at least the same 
reasons as the claims on which they depend. 
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Please apply any charges or credits to deposit account 06-1050, referencing attorney 
docket no. 12144-010001. 

Respectfully submitted, 



Date: March 29. 2007 /Misha K. Hill/ 

Misha Kim Hill, Reg. No. 59,737 

Fish & Richardson P.C. 
225 Franklin Street 
Boston, MA 02110 
Telephone: (617) 542-5070 
Facsimile: (617)542-8906 

21593879.doc 



